Many organizations store financial data, manufacturing data and other critical data in databases or other electronic storage formats. For purposes of understanding the data, the data must be reported in some form that makes sense to human or programmatic users. In other words, users typically want to see quantitative information “by” some criteria. For example, a user may want to see sales in dollars by month, by cost center, by region and so on. The data used to enforce the criteria is referred to as reference data. Oftentimes, individual pieces of reference data are interrelated in some manner. For example, the piece of reference data representing a cost center can be related to the piece of reference data representing a geographical region. The organization of the reference data to reflect these relationships is referred to as its hierarchy.
A single organization can have multiple systems for storing and reporting data. Often, these systems are heterogeneous, with each system having its own hierarchy or hierarchies for reference data. FIG. 1 is a diagrammatic representation of a prior art system for storing and reporting data. In FIG. 1, system 100 can include an accounting system 102 having hierarchy 104 for organizing data in database 106 and electronic transaction system 108 having hierarchy 110 for organizing data in database 107. Each hierarchy can organize different or overlapping sets of reference data according to different criteria. For example, hierarchy 104 can organize data of interest according to the corporate organization, with the reference data indicating the department, the section and the cost center associated with the piece of data. Hierarchy 110, on the other hand, can organize the data geographically according to continent, country region and cost center. Typically a system using a particular hierarchy, such as hierarchy 104, will have no knowledge of the hierarchies employed by other systems, even if a portion of the reference data overlaps.
To further complicate matters, other systems that use the data may have their own hierarchies for reporting the data. A financial reporting system 114, for example, can have its own hierarchy 116 to organize data imported from accounting system 102 or transaction system 108 into reports for users. Reporting hierarchy 116 can require, for example, that data be accessed based on country and department, requiring coordination of hierarchy 104 and hierarchy 110 to access data. An Extract Transform Load (“ETL”) system 118 can map data from accounting system 102, electronic transaction system 108 and other systems to financial reporting system 114.
Current systems suffer several shortcomings in managing multiple hierarchies, particularly when the hierarchies change. Suppose local users in an organization decide to add an additional cost center for the purposes of tracking electronic transactions. In this case, hierarchy 110 can be updated to associate the new cost center with particular pieces of transaction data. However, since accounting system 102 does not have knowledge of hierarchy 110, the update to hierarchy 110 will not change hierarchy 104, meaning that accounting system 102 and electronic transaction system 108 are tracking transactions according to a different set of cost centers. While this is just one example of change in one hierarchy that should be reflected in another hierarchy, there may be a great many changes due to new cost centers being added, products changing product lines or names, revised accounting standards or other circumstances that require changes to be propagated to multiple hierarchies, particularly in a large organization.
Management of hierarchy changes in prior art systems was often handled manually. Continuing with the example above, an administrator of electronic transaction system 108 would notify an administrator of accounting system 102 via email or other communication of the addition of the new cost center to hierarchy 110 and the second administrator will try to update hierarchy 104 accordingly. Additionally, the mappings of ETL system 118 could then be updated, typically through implementation of custom code, so that the augmented hierarchies 110 and 104 could be mapped to hierarchy 116. When a large number of changes are made to hierarchies, updating other hierarchies and mappings becomes an increasingly time consuming and error prone process.
Another shortcoming of many prior art systems is the lack of effective management of business rules across hierarchies. Often, knowledge of business rules is owned at a departmental or individual user level. The rules can be buried in hard-coded system interfaces, spreadsheets and desktop databases. Consequently, a particular user or set of users may not have knowledge of various business rules implicated for a particular hierarchy change. From the perspective of business transaction system 108, the addition of a cost center may not be restricted, however, from the perspective of accounting system 102, a business rule may exist that new cost centers should not be added for regulatory reasons. Therefore, while a new cost center can be added to hierarchy 110, the same cost center can not be added to hierarchy 104, leading to a discrepancy between cost centers used by different hierarchies. Such discrepancies across hierarchies can cause minor inconvenience or lead to significant errors in financial and regulatory reporting.